\section{Análisis de riesgos}

%textbf es para que este en negrita
%textbf{}
%el itemize es para item, como numeracion y viñetas en word


\textbf{Riesgo 1}
\begin{itemize}
\item \textbf{Descripción}: Dada que puede haber fallas en los dispositivos externos (Ej: sensores de pulso y de oxígeno), es probable que esto acarree la ausencia de datos necesarios para hacer cálculos.
\item \textbf{Probabilidad}: Baja
\item \textbf{Impacto}: Medio
\item \textbf{Exposición}: Media
\item \textbf{Mitigación}: Contar con mecanismos de diagnóstico del estado de los dispositivos, manejo de excepciones (en el código) y circuito de reposición de hardware dañado.
\item \textbf{Contingencia}: Contar con mecanismos de cálculo estimativo en base a otros parámetros en los casos donde sea posible. En el caso de datos vitales, notificar al usuario de dicha falencia.
\end{itemize}

\textbf{Riesgo 2}
\begin{itemize}
\item \textbf{Descripción}: Dado que el sistema puede sobrecargarse (riesgo arquitectural), es probale que el sistema no pueda soportar la cantidad de usuarios concurrentes, tráfico de datos, solicitudes concurrentes, ataques a la disponibilidad del sistema (denial of service), o bien por tratarse de una carga superior a la prevista por el hardware actual. En un escenario de aumento sostenido de demanda de recursos que supere las prestaciones del hardware, el sistema podría colapsar.
\item \textbf{Probabilidad}: Media
\item \textbf{Impacto}: Alto
\item \textbf{Exposición}: Alta
\item \textbf{Mitigación}: Diseñar una arquitectura empleando tácticas para lograr los atributos de calidad adecuados. Monitorear el progreso en el tiempo de los recursos utilizados por el sistema. Brindar informes periódicos a los stakeholdes con un resumen de los recursos utilizados (volúmenes de datos, intentos de ataques, horarios pico, up-time, etc), permitiendo su análisis y comparación a través del ciclo de vida del sistema, de modo de poder prever las necesidades de infraestructura futura del sistema. Hacer estudios de performance, ajustando la implementación actual por otras más rápidas, o que consuman menos recursos, o ambas, según sea el caso.
\item \textbf{Contingencia}: Se podría negociar con los stakeholders para solicitar más inversión en hardware, respaldando los argumentos con los informes técnicos en donde se evidencia lo señalado. Se podría limitar el ingreso y uso del sistema a una cantidad máxima de usuarios concurrentes, de modo de asegurar cierta calidad de servicio (ej: 1000 usuarios concurrentes). En caso de no llegar a un acuerdo político de los limites de capacidad del sistema, se podría someter el dimensionamiento del sistema a especialistas externos.
\end{itemize}

\textbf{Riesgo 3}
\begin{itemize}
\item \textbf{Descripción}: Dada la posiblidad de caída de servicios en la nube (riesgo técnico), es probable que los corredores no puedan acceder a datos.
\item \textbf{Probabilidad}: Baja
\item \textbf{Impacto}: Medio
\item \textbf{Exposición}: Media
\item \textbf{Mitigación}: Concebir en el sistema la posibilidad de que los datos puedan residir en otros repositorios y hacer las abstracciones necesarias para brindar dicha flexibilidad evitando restricciones a un tipo de implementación de persistencia de datos en particular.
\item \textbf{Contingencia}: Proveer los datos lo mas actualizados posibles e intentar estimarlos mediante otros parámetros en run time de ser posible.
\end{itemize}

\textbf{Riesgo 4}
\begin{itemize}
\item \textbf{Descripción}: Dado que algunos servicios necesarios para la aplicación pueden no estar disponibles (riesgo técnico). es probable que la aplicación no pueda dar su servicio. 
Por ejemplo, Google Maps presenta una caída durante un lapso de tiempo pronunciado, siendo un servicio usualmente confiable sobre el que esta basada la aplicación y vital para el funcionamiento del sistema.
\item \textbf{Probabilidad}: Baja
\item \textbf{Impacto}: Medio
\item \textbf{Exposición}: Media
\item \textbf{Mitigación}: No depender de un único servicio de mapping. Para ello es necesario dotar al sistema de la flexibilidad para que la aplicación permita utilizar otro servicio de mapping.
\item \textbf{Contingencia}: Recurrir a otro recursos que provean el mismo servicio o usar datos internos recopilados.
Esperar a que el servicio se restablezca y acumular las solicitudes de visualización en el mapa de los datos generados en tiempo real, para su posterior procesamiento.
\end{itemize}

\textbf{Riesgo 5}
\begin{itemize}
\item \textbf{Descripción}: Dado el estado experimental y desconocimiento de la metodología de encriptación homomórfica (HE), es muy probable que se retrase el cumplimiento de este requerimiento.
\item \textbf{Probabilidad}: Alta
\item \textbf{Impacto}: Medio
\item \textbf{Exposición}: Alta
\item \textbf{Mitigación}: Considerar métodos de encriptación alternativos más sencillos y más rápidos para implementar.
\item \textbf{Contingencia}: Debería considerarse salir a producción sin la funcionalidad, o negociar la aprobación de la compra de productos que lo implementan y que el presupuesto lo permita.
\end{itemize}

\textbf{Riesgo 6}
\begin{itemize}
\item \textbf{Descripción}: Dado que tenemos un caso de uso basado en que la aplicación soporte reconocimiento de voz y no conocemos cómo hacerlo ni tenemos experiencia en esas tecnologías, es muy probable que el proyecto se atrase o no podamos cumplir con esta funcionalidad.
\item \textbf{Probabilidad}: Alta
\item \textbf{Impacto}: Medio
\item \textbf{Exposición}: Alta
\item \textbf{Mitigación}: Contar con una lista acotada de pedidos posibles a través de la voz del usuario.
\item \textbf{Contingencia}: Quitar esa funcionalidad si la versión actual de la aplicación no logra alcanzar niveles de satisfacción del usuario aceptables, hasta tanto la misma logre el nivel de madurez necesario para resultar de utilidad a los usuarios.
\end{itemize}

\textbf{Riesgo 7}
\begin{itemize}
\item \textbf{Descripción}: Dado que la aplicación podría adolecer de controles de seguridad y auditoría de la actividad del sistema, ya sea internos o externos (por parte de Defensa del Consumidor, del Ministerio, etc), es probable que el sistema no proteja los datos considerados sensibles y personales de los usuarios, pudiendo derivar en problemas de indole legal que lleven a cambiar de sistema por otro más transparente.
\item \textbf{Probabilidad}: Media
\item \textbf{Impacto}: Alto
\item \textbf{Exposición}: Alta
\item \textbf{Mitigación}:  Analizar la configuración del sistema para que se pueda verificar que el mismo no filtre cosas que no debería filtrar y viceversa. Usar mecanismos de encripción de datos. Armar casos de test de seguridad al respecto.
\item \textbf{Contingencia}:  En caso de registrarse reclamos, atender los mismos a la brevedad para demostrar la seriedad con la que se encara la solución. Ver si los mismos se deben a una mala implementación o se pueden corregir reconfigurando el sistema. En el primer caso, debería corregirse el error en el código a la brevedad.
\end{itemize}

\textbf{Riesgo 8}
\begin{itemize}
\item \textbf{Descripción}: Dado que nos solicitan que trabajemos bajo las especificaciones de OpenSocial cuyos servicios y especificaciones no conocemos, 	es muy probable que el proyecto se atrase o bien se utilicen servicios mas conocidos por nuestro equipo de trabajo.
\item \textbf{Probabilidad}: Alta
\item \textbf{Impacto}: Medio
\item \textbf{Exposición}: Alta
\item \textbf{Mitigación}: Capacitar al equipo lo antes posible en este tema. Si no se trata de algo sencillo, evitar su uso y/o buscar soluciones comerciales alternativas no abiertas pero más conocidas por la comunidad de desarrolladores. 
\item \textbf{Contingencia}: Negociar que nos den mas tiempo para cumplir con el requerimiento. Hacer una re-estimación realista del tiempo que demandará, tratando de evitar nuevas postergaciones.
\end{itemize}

\textbf{Riesgo 9}
\begin{itemize}
\item \textbf{Descripción}: Dado que nos tienen que enviar los dispositivos Google Glass hasta una determinada fecha para probar la interacción con nuestra aplicación, si se atrasa la entrega de los mismos, no podremos realizar las pruebas pertinentes y verificar el funcionamiento correcto.
\item \textbf{Probabilidad}: Media
\item \textbf{Impacto}: Alto
\item \textbf{Exposición}: Alta
\item \textbf{Mitigación}: Hacer un seguimiento y exigir la entrega inmediata de los mismos antes que el equipo deba comenzar a desarrollar sobre ellos. Comunicar y explicar que de no ser provistos en tiempo y forma, el proyecto se retrasará inexorablemente.
\item \textbf{Contingencia}: Comunicar y dejar asentada la demora correspondiente, cuya responsabilidad es ajena al equipo de desarrollo. Correr el cronograma en consecuencia. Intentar hacer otras tareas, de ser posible, a la espera de los dispositivos. Si el hardware no es entregado en un tiempo prudencial, quitar las funcionalidades relacionadas con éste o bien mockear el código simulando su existencia de ser posible.
\end{itemize}

\textbf{Riesgo 10}
\begin{itemize}
\item \textbf{Descripción}: Dado que es requerimiento del proyecto almacenar la información en OpenStack, una "nube" de la cuál no conocemos su funcionamiento ni los servicios que presta,  es muy probable que el proyecto sufra atrasos hasta que nos interioricemos en el tema.
\item \textbf{Probabilidad}: Alta
\item \textbf{Impacto}: Medio
\item \textbf{Exposición}: Alta
\item \textbf{Mitigación}: Capacitar al equipo lo antes posible en este tema. Si no se trata de algo sencillo, evitar su uso y/o buscar soluciones comerciales alternativas no abiertas pero más conocidas por la comunidad de desarrolladores. 
\item \textbf{Contingencia}: Negociar que nos den mas tiempo para cumplir con el requerimiento. Hacer una re-estimación realista del tiempo que demandará, tratando de evitar nuevas postergaciones.
\end{itemize}

\textbf{Riesgo 11}
\begin{itemize}
\item \textbf{Descripción}:  Dado que la nube es un componente que no sabemos cómo funciona ni que prestaciones de performance y disponibilidad nos asegura (SLA), es altamente probable que si el servicio no está disponible o bien es lento, no podamos solucionarlo ni cumplir con dicha funcionalidad.
\item \textbf{Probabilidad}: Alta
\item \textbf{Impacto}: Alto
\item \textbf{Exposición}: Alto
\item \textbf{Mitigación}: Verificar lo antes posible si se cumple con el SLA que aseguran brindar. Hacer pruebas para medir disponibilidad y performance. Reclamar y comunicar formalmente si no cumplen con lo pactado. Listar alternativas en caso que este servicio sea de baja calidad.
\item \textbf{Contingencia}: Cambiar por otro proveedor de cloud computing (quizás mas caro). De no ser viable, intentar bajar las expectativas de performance y disponibilidad requeridas.
\end{itemize}

\textbf{Riesgo 12}
\begin{itemize}
\item \textbf{Descripción}:  Dado que la nube es administrada por personal externo al proyecto, es altamente probable que si no nos envían las cuentas y las configuraciones necesarias, no podamos proceder con el cumplimiento de dicho requerimiento. funcionalidad.
\item \textbf{Probabilidad}: Alta
\item \textbf{Impacto}: Medio
\item \textbf{Exposición}: Alto
\item \textbf{Mitigación}: Tener un canal de comunicación y contacto fluido con los proveedores del servicio para poder reclamar a tiempo temas administrativos y de redes minimizando lo más posible las demoras. 
\item \textbf{Contingencia}: Al igual que el riesgo anterior, se podría solicitar se opte por otro proveedor de cloud computing y en caso de ser imposible, asentar y responsabilizarlos, en lo que a ellos respecte, de las demoras en el proyecto.
\end{itemize}

\textbf{Riesgo 13}
\begin{itemize}
\item \textbf{Descripción}:  Dado que nos solicitan que la aplicación funcione en varios dispositivos que aún no están en el mercado (por ejemplo Google Glass), es altamente probable que no podamos cumplir esto ya que desconocemos la interfaz que utilizarán ni tenemos experiencia en dispositivos similares.
\item \textbf{Probabilidad}: Alta
\item \textbf{Impacto}: Medio
\item \textbf{Exposición}: Alto
\item \textbf{Mitigación}: Diseñar la aplicación teniendo en cuenta la portabilidad y modificabilidad producto de las diversidad tecnológica presente y futura. Capacitar al equipo de modo que se especialicen en la temática. Otra alternativa sería requerir servicios de consultoría para temas especificos, si el presupuesto lo permite.
Para el caso de dispositivos mas concretos que sabemos que debemos utilizar, la capacitaciòn en el mismo es imprescindible para minimizar el riesgo.
\item \textbf{Contingencia}: Explicitar la lista de modelos que no son soportados por la aplicación para no generar falsas expectativas de compatibilidad. Alentar el uso de modelos que sí funcionan con la aplicación.
\end{itemize}

\textbf{Riesgo 14}
\begin{itemize}
\item \textbf{Descripción}:  Dado que tenemos un único arquitecto en el sistema, es poco probable que se vaya del equipo y no podamos desarrollar la arquitectura de nuestro proyecto
\item \textbf{Probabilidad}: Baja
\item \textbf{Impacto}: Alto
\item \textbf{Exposición}: Alta
\item \textbf{Mitigación}: Tener más de un recurso abocado al conocimiento y diseño de la arquitectura. 
\item \textbf{Contingencia}: En última instancia, ofrecerle reconsiderar su decisión haciéndole más atractiva su permanencia proponiéndole aumentarle el sueldo de ser necesario, brindarle beneficios extras, y escuchar cuáles son los motivos de su partida y analizar si es posible atender a sus demandas con el fin de retenerlo en el equipo.
\end{itemize}


%fin de los items
